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Prufungsantrag gem. § 44 PatG ist gestelit 

@ Verfahren zum Test eines objektorientierten Programms 

(g) Mit der Erfindung wird ein Verfahren vorgestellt, das zum 
Test objektorientierter Programme diejenigen Programm- 
stellen, welche von der Kommunikation der Objekte unter- 
einander betroffen sind instrumentiert. Beim Ablauf des 
Programms warden samtliche Kommunikationsvorgange 
zwischen den Objekten mit zugehorigen Parametern in einer 
Protokolidatei aufgezeichnet. Diese Protokolidatei wird an- 
schlieBend geeignet aufbereitet, so daS z. B. durch eine 
grafische Darstellung direkt die Ergebnisse des objektorien- 
tierten Designs mit dem Ablauf des Programms verglichen 
werden konnen. 
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Beschreibung 

In vermehrtem Umfang hat sich bei der Erstellung umfangreicher Programme dieTechnik des objektorien- 
tierten Programmierens etabliert. Diese Technik bietet sowohl bei der Erstellung der Programme als auch beim 
Ablauf verschiedenste Vorteile. _ . . . 

Dem Programmierer wird beispielsweise das stmkturierte Programmieren erleichtert. Weiterhin ist es ein- 
fach Klassen aus bereits vorhandenen Programmen fur neue Programme zu ubernehmen. Da Objekte zur 
Laufzeit erzeugt und auch wieder geldscht werden konnen, wird zu jedem Zeitpunkt des Ablauts nur der aktuell 
benotigte Speicher beansprucht. Im Zusammenhang mil der Erstellung der objektorientierten Programme hat 
sich die Technik des OOD (object oriented design) [1] durchgesetzt. Diese Technik macht sich grafische 
Eingabemoglichkeiten bei der Erstellung von Programmen zunutze und ist in [2]-[5] naher erlautert 

Schwierigkeiten bestehen zur Zeit beim Test objektorientierter Programme. Dies hegt insbesondere an der 
dynamischen Struktur beim Ablauf dieser Programme. Da wahrend des Programmablaufs Objekte erzeugt und 
wieder geloscht werden, sowie Methoden aufgerufen werden, ist es schwierig, bei einem Test alle Objekte und 
15 Methodenaufrufe bezuglich ihrer Richtigkeit und ihrer Parameter zu iiberpriifen. 

Verf ahren und Werkzeuge, die einen umfangreichen Test von objektorientierten Programmen zulassen, sind 
derzeit nicht bekannt. . 

Der im folgenden erlauterten Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Test eines objekt- 
orientierten Programmes anzugeben. 

Diese Aufgabe wird gemaB den Merkmalen des Patentanspruchs 1 gelosL 
Weiterbildungen der Erfindung ergeben sich aus den Unteranspruchen. 

Da die Funktion objektorientierter Programme auf der Kommunikation der Objekte untereinander basiert, 
wird bei der Erfindung in vorteilhafter Weise die Kommunikation der Objekte untereinander analysiert Dies 
geschieht erfmdungsgemaB dadurch, daB alle kommunikationsrelevanten Stellen in den Programmen, d. h. in den 
Klassen und in den Methodenaufrufen dahingehend instrumentiert werden, daB die testrelevante Information 
(z. B. Methodenname, Parameterwerte, Aufrufer und gerufenes Objekt) beim beispielsweise Methodenaufruf 
oder beim Instantiieren bzw. Loschen eines Objekts in einem separaten Protokoll festgehalten werden konnen. 
Ein weiterer Bestandteil des erfindungsgemaBen Verfahrens besteht in der vorteilhaften Auswertung einer 
erstellten Protokolldatei. Hierdurch wird einem Testenden der Programmablauf ubersichtlich dargestellt 

In vorteilhafter Weise geschieht die Veranschaulichung des Programmablaufs in grafischer Art. Wenn man 
diese Darstellung so wahlt, daB sie der grafischen Representation beim object oriented design entspricht, so 
kann man einfach manuell oder automatisch die Spezifikation des Programmes mit dem tatsachlichen Ablauf 
vergleichen. . 

Die erfindungsgemaB vorgesehene Instrumentierung fur Methoden bietet den Vorteil, daB man beim Test 
leicht uberprufen kann, mit welchen Parametern welche Methode aufgerufen wurde. Weiterhin kann man 
statistisch auswerten, wie oft eine Methode aufgerufen wurde. Durch die Instrumentierung der Methodenaufru- 
fe gewinnt man Informationen uber die ubergebenen Parameter und dariiber, mit welchen Methodenaufrufen 
welche Methoden in welchen Objekten aufgerufen werden. Durch die Instrumentierung von beispielsweise den 
Methodenaufrufstellen in den verschiedenen Objekten gewinnt man Informationen, die man vor alien Dingen 
40 fur die Analyse verketteter Methodenaufrufe benotigt. Verkettete Methodenaufrufe sind solche Methodenauf- 
rufe, die beispielsweise von einem Objekt ausgehen und in einem weiteren Objekt wiederum einen Methoden- 
aufruf bewirken und welcher dann in einem nachsten Objekt wieder eine Methode aufruf en kann. 

Ein Vorteil des erfindungsgemaBen Verfahrens besteht vor alien Dingen in der Erstellung von Objektbilanzen. 
Damit laBt sich statistisch leicht feststellen, welche und wie viele Objekte von welchen Klassen wahrend des 
Programmablaufs instantiiert wurden. Weiterhin kann man daraus ersehen, ob alle aufgerufenen Objekte auch 
wirklich benutzt wurden und ob mit den Methoden die richtigen Objekte angesprochen wurden. Man erkennt 
auch leicht, ob alle instantiierten Objekte auch wieder geloscht worden sind. 

Weiterhin gewinnt man so die Moglichkeit, die Tatigkeit des Programmierers uberwachen zu konnen. Haufig 
gibt es in groBeren Unternehmen an Programmierer die Anweisung, bereits erstellte Klassen oder Programm- 
teile in neuen Programmen wieder zu verwenden. Mit dem erfindungsgemaBen Verfahren kann man nun leicht 
uberprufen, ob die Klassen, die in ein neues Programm eingebunden wurden, auch verwendet werden, oder ob 
sie nur einen quasi unnotigen Ballast im Programmcode darstellen. 

Im folgenden wird die Erfindung anhand von Figuren und Beispielen weiter erlautert 
Fig. 1 zeigt als Beispiel ein Blockschaltbild des erfindungsgemaBen Verfahrens. 
55 Fig. 2 zeigt die Spezifikation eines objektorientierten Programmes. 
Fig. 3 zeigt die Realisierung des Programmes von Fig. 2. 

Fig. 1 zeigt als Beispiel ein Blockschaltbild des erfindungsgemaBen Verfahrens. Mit I/O ist die Aus- und 
Eingabe des spezifizierten und nicht instrumentierten objektorientierten Programmes bezeichnet. Mit IP ist das 
instrumentierte objektorientierte Programm dargestellt. P bezeichnet die Protokolldatei, die beim Test erstellt 
wird. TAP stellt das Test-Auswerteprogramm dar, mit dem die beim Test erstellte Protokolldatei aufbereitet 
wird. SD heiBen die Spezifikationsdaten, mit denen das objektorientierte Programm spezifiziert wurde. Ober das 
Test-Auswerteprogramm TAP konnen die aufbereiteten Protokolldaten beispielsweise auf einem PC auf einem 
Drucker und in einer Datei F ausgegeben werden. In diesem Beispiel des erfindungsgemaBen Verfahrens 
geschieht beim Testen eines objektorientierten Programmes folgendes. Die Original- Eingaben, die I/O, werden 
dem instrumentierten objektorientierten Programm IP zugefuhrt. Beim Abarbeiten des instrumentierten Pro- 
grammes IP werden die Eingabedaten I/O verarbeitet und falls im Programm IP instrumentierte Programmteile 
angesprochen werden, ergeben sichTestprotokoll-Daten, welche in einer Protokolldatei P oder einem Protokoll 
P abgelegt werden. Die Ausgabe-Daten von IP entsprechen dabei den Ausgabe-Daten des nicht instrumentier- 
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ten Programmes. Beispielsweise sind in dem objektorientierten Programm Methoden und Aufrufstellen von 
Methoden in Objekten instrumentiert Insbesondere konnen bei in C+ + erstellten Programmen beispielsweise 
alle Memberfunktionen, statische Memberfunktionen, Konstruktoren, Destruktoren, uberladene Operatoren, 
Friends und Casts instrumentiert sein. 

AnschiieBend wird das Protokoll P beispielsweise durch das Test-Auswerteprogramm TAP ausgewertet. Im 5 
Zuge der Auswertung kann die Protokolldatei beispielsweise grafisch dargestellt werden. Erne besonders 
geeignete Form der grafischen Darstellung bietet jenes grafische Format, welches beim Spezifizieren des 
Programmes im Zuge des objektorientierten Designs verwendet wurde. Man kann so leicht im Vergleich von 
Protokoll-Daten mit den Spezifikationsdaten SD Unterschiede zwischen Programm und zugehonger Spezifika- 
tion feststellen. Es besteht die Moguchkeit, diese Unterschiede am Bildschirm oder am Drucker auszugeben oder J0 
auch in einer Datei abzuspeichern, um sie weiterverarbeiten zu konnen. Bei der Analyse des Protokolls P durch 
das Test-Auswerteprogramm TAP sind auch noch andere Auswertemethoden denkbar. Beispielsweise kann die 
Objektiandschaft angezeigt werden. Das bedeutet, zu einem aktuellen Zeitpunkt oder fur einen Zeitabschnitt 
konnen alle existierenden Objekte ausgegeben werden. Weiterhin ist es denkbar, einen Methodenaufrufbaum 
darzustellen. Dieser Methodenaufrufbaum zeigt alle weiteren Methodenaufrufe an, die ein selektierter Metho- is 
denaufruf zur Folge hat Weiterhin kann man sich denken, die Objektiandschaft mit Aufrufbeziehung anzeigen 
zu lassen, wobei alle jemals existenten Objekte einschlieBlich ihrer gegenseitigen Methodenaufrufe angezeigt 
werden kSnnen. Zusatzlich ist es denkbar, die Klassenlandschaft mit ihren Aufrufbeziehungen darzustellea Dies 
hat zur Folge, daS alle existierenden Klassen einschlieBlich ihrer Methodenaufruf-Beziehungen untereinander 
gezeigt werden. Alle diese vorab aufgezahlten Darstellungen werden in den verschiedenen OOD-Methoden zur 20 
Spezifikation eines objektorientierten Programmes verwendet In analoger Weise kann man die Protokolldatei 
auf statistische Merkmale hin analysieren. Beispielsweise konnen alle Objekte gezahlt werden. Es konn n 
samtliche Methodenaufrufe gezahlt werden, und man kann uber eine Analyse der maximal und minimal existie- 
renden Objekte bzw. Methodenaufrufe Aussagen uber die Programrn-Komplexitat machen. 

Fig. 2 zeigt ein objektorientiertes Programm in grafischer Darstellung nach Art des objektorientierten De- 25 
signs (OOD). Es sind drei Objekte ol bis o3 aus zugehorigen Klassen Kl bis K3 dargestellt ol ruft beim Objekt 
o2 eine Methode ma mit den Parametern x und y auf. ol ruft auch beim Objekt o3 eine Methode mb mit den 
Parametern z, x und c auf. Fig. 2 zeigt hier beispielsweise die Spezifikationsform des objektorientierten Pro- 
grammes. Fur diese Spezifikation folgt nun der Source-Code des objektorientierten Programmes. 



l.C-f + -Source-Code 
Im folgenden wird das Beispiei in C + 4- -Syntax beschrieben. 

class K1 { 

public: 
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void m() [ 40 

K2 02; // standard constructor call 

K3 o3; // standard constructor call 

fnt x=1, 
y = 2; 
float 2 = 1.5; 
char c = ' 
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// other statements of the method 

02. ma(x,y); 55 

// other statements of the method 

03. mb(z, x, c); 

60 

// other statements of the method 

} 
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class K2 { 

public: 



voidma(intp,intq){ 

// statements of the method 

} 



class K3 { 

public: 

25 void mb(float I, int m f char n) { 

// statements of the method 



} 



void mainO { 

K1 o1 ; // standard constructor call 



//other statements 

otmO; 



//other statements 



Fur das gezeigte Beispiel folgt nun der nach dem erfindungsgemaBen Verfahren instrumentierte Source-Code, 
so Darin sind die instrumentierten Stellen durch Fettdruck hervorgehoben. 
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2.InstrumentierterC+ +■ -Source-Code 

class K1{ 

public: 

K10 

{ II standard constructor was added 

protfile«"callK1::K10\n n 

« "in fOe ... at line ... happenedta"; 
pratfile « "parameters:^ 11 ; 
pratfile « "now"; 

} 

void mO { 

pratfile « "call K1::m()\n' 

« "in file ~ at line ... happened^"; 
pratfile « "parameters:^ 11 ; 
pratfile «"no\n"; 

K2 o2; // standard constructor call 

pratfile « "del K2 o2 in K1 :snO\n" 

« "in file ...at fine. .An"; 
K3o3; //standard constructor call 
pratfile « "del K3 o3 in K1 ::mOW 

« "in file ...at line ..An"; 
intx = 1, 
y-2; 
float z =1.5; 
chares 1 *'; 



// other statements of the method 

pratfile « "call o2.ma(x, y) from class K2W 

« "in K1::m0 in file ... at line ... started\n°; 
pratfile « "parametersAn"; 
pratfile « " int x s ■ « x « int y = " « y « "to"; 
o2.ma(x, y); 

pratfile « "call o2.ma(x, y) from class K2\n u 

« "in K1::m0 in file ... at line ... ended\n u ; 
protfile« n parameters:\n"; 
pratfile « ■ mtxs" «x« mty= ° «y « "\n u ; 
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// other statements of the method 

protfile « "call o3.mb(z, x, c) from class K3\n" 

« n in K1::m0 in file ... at line ~ startedVn"; 
protfile « "parameters:^"; 
protf i le « " f loat z s tt « z « ° , I nt x s 0 « x 

« n , char c = ■ « c « "to"; 
o3.mb(z, x, c); 

protfile « "call o3.mb(z, x, c) from class K3\n" } 

« "in K1::m0 in file ... at line .„ ended\n u ; 

protfile « "parameters^"; 

protfile « " float z = ■ « z « ", int x s ■ « x 
« °, char c = ■ « c « "\n" ; 

// other statements of the method 



class K2 { 

public: 

30 

K20 

{ // standard constructor was added 

protfile « "call K2::K2Q\n n 
35 « "in file ... at line «. happened\n n ; 

protfile « n parameters:\n H ; 
protfile « "noVn"; 
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} 

voidma(intp, intq) { 

protfile « "call K2::ma(p,q)\n u 

« "in file at line ... happenedta"; 
protfile « "parameters at the begin of K2::ma(p,q):\n"; 
protfile « u int p = " « p « u , int q = " « q « "Vn"; 

so // statements of the method 

protfile « "parameters at the end of K2::ma(p,q):\n 0 ; 
protfile« u intp="«p« n , intq= D «q« n \n u ; 

} 

55 } 
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class K3 { 
public: 

K30 

{ II standard constructor was added 

protfile« D call K3::K30\n" 

« "in file ... at line ... happenedto"; 
profile « "parameters:^"; 
protfite«"no\n"; 

} 

void mb(float I, int m, char n) { 

protfite « "caU K3::mb(l, m, n)\n n 

« "in file ... at line ... happened\n°; 
protfile « "parameters at the begin of K3::mb{l, m, n):\n° 
protfile « 0 float I = ' « I « int m = D « m 

« n ,charn= B «c«°\n n ; 

// statements of the method 

protfile « "parameters at the end of K3::mb{l, m, n):\n°; 
protf ile « ■ float I ■ " « I « ", int m = n « m 
« ", char n s " «c « "to"; 

} 

} 



voRjmainO{ 

{ofstream protfilefprotocot"); 

protfile « "call mainOVi" 

« "in file ... at line ... happened^"; 
protfile « "parameters^"; 
protfile « B no\n"; 
K1o1; 

protfile « "del K1 ol in malnOta" 
« "in file ... at line ...\n"; 



//other statements 
protfile « "call o1 jnO from class K1\n" 

« "in mainO in file ... at line ... started\n"; 
protfile « n parameters:\n D ; 



//protocol file} 



// standard constructor call 
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protfi!e« tt no\n tt ; 
ol.mO; 

protf ile « B ca1l ol jn() from class K1\n" 
5 « "in mainO in file ... at line .» endecftn 0 ; 

protfile « D parameters:\n n ; 
protfile« n no\n B ; 

10 //other statements 



15 Es ist hier zwar der Source-Code instrumentiert, doch ist es auch moglich, wenn man geniigend Kenntnis iiber 
die eingesetzte Hardware hat und den entsprechenden Compiler in Verbindung mit dem Objektcode, der fiir das 
objektorientierte Programm erzeugt wird, gut kennt, daB die entsprechende Instrumentierung auch auf der 
Objektcode-Ebene erfolgt 

Hier ist nur die Instrumentierung des Source-Codes gewahlt worden, um ein anschauliches Beispiel darstellen 
20 zu konnen. Dieser instrumentierte Source-Code fiihrt zu einer Ausgabeprotokolldatei, die im AnschluB folgt 

3. Ausgabe der Protokolldatei 

Die beim Ablauf des Programmes (main function) erstellte Protokolldatei ist im folgenden aufgelistet Die 
25 eingefiigten Leerzeilen dienen ausschlieBlich der besseren Lesbarkeit 

Die angegebenen Parameterwerte sind naturlich nur exemplar isch, sie hangen logischerweise von den hier 
nicht im etnzelnen aufgefiihrten Statements in den Methodenriimpfen ab. Ebenso sind bei der Ausgabe von "in 
file ... at line ..." die angegebenen drei Punkte (" . . . ") jeweils durch den aktuellen Dateinamen und durch die 
aktuelle Zeilennummer im (nicht instrumentierten) Source-Code ersetzt. 
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call mainO 

in file ... at line ... happened 

parameters: 

no 

call K1::K10 

in file ... at line ... happened 

parameters: 

no 

del K1 o1 in mainO 
in file ...at line ... 

cad o1 jtiO from class K1 

in mainO h file ... at line ... started 

parameters: 

no 

callK1::mO 

in file ... at line ... happened 

parameters: 

no 

caHK2::K20 

in file ... at line ... happened 

parameters: 

no 

dclK2o2inK1::mO 
snfSe ...at line ... 

callK3::K30 

in file ... at fine ... happened 

parameters: 

no 

dclK3o3inK1::mO 
in file ...at line ... 

call o2.ma(x, y) from class K2 
in K1::m0 in file ... at line ... started 
parameters: 
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intx=1,inty=2 

call K2;:ma(p, q) 
in file ... at line ... happened 
parameters at the begin of K2::ma(p, q): 
intp = 1,intq = 2 

parameters at the end of K2::ma(p, q): 
intp = 1Jntq = 2 

call o2.ma(x, y) from class K2 
in K1:.to0 in file ... at line ... ended 
parameters: 
intx = 1,inty=2 

call o3.mb(z, x, c) from class K3 
in K1 ::m0 in file ... at line ... started 
parameters: 

f loat z = 1 .5, int x = 1 f char c = * 

call K3::mb(l, m, n) 
in file ... at line ... happened 
parameters at the begin of K3::mb(I, m, n): 
float I = 1.5, int m = 1, char n = * 

parameters at the end of K3::mb(l, m, n): 
float I = 1.5, int m = 1, char n = * 

call o3.mb(z, x, c) from class K3 
in K1 ::m() in file ... at line ... ended 
parameters: 

float z = 1 .5, int x = 1, char c = * 

call o1 .m0 from class K1 

in matnO in file ... at line ... ended 

parameters: 

no 

Mit dem erfindungsgemaBen Verfahren wird nun Qber die Aufbereitung durch das Test-Auswerteprogramm 
TAP die grafische Darstellung von Fig. 3 erzeugt. Sie zeigt drei Objekte ol, o2 und o4, wobei ol am Objekt o2 
die Methode ma mit den Parametern x und y aufruft und am Objekt o4 die Methode mb mit z, x und c aufruft 
Hier ist deutlich zu erkennen, daB Fig. 3 im Vergleich zur Spezifikation, welche in Fig- 2 dargestellt ist, eine 
Abweichung aufweist. 

in Fig. 3 wird die Methode mb namlich am Objekt o4, anstatt am Objekt o3 aufgerufen, was nicht mit dem 
Design ubereinstimmt Analog dazu konnen beispielsweise weitere Abweichungen vom Design, wie z. B. fehlen- 
de oder zusatzliche (und damit eventuelle uberflussige) Methodenaufrufe ermittelt werden. 

Wichtig ist es, beim erfindungsgemaBen Verfahren zu beachten, daB die durch die Instrumentierung des 
Source-Codes beispielsweise ermittelte Protokolldatei nur als Mittel zum Zweck dient. Wesentlich ist es, daB die 
Protokolldatei weiterverarbeitet wird und geeignet beispielsweise grafisch aufbereitet wird. Geeignet bedeutet 
in diesem Zusammenhang, daB die Aufbereitung in Affinitat zur Darstellung in der Phase des objektorientierten 
Designs erfolgt. Ein Ziel ist es hierb i beispielsweise, den eigentlichen Programmablauf anschlieBend direkt mit 
dem Design, d. h. mit den Ergebnissen aus der OOD-Phase vergleichen zu konnen. 

Insbesondere kann die Instrumentierung des zu testenden Programmes auch vorteilhaft automatisiert durch 
ein hier nicht naher beschriebenes Instrumentierungs-Programm erfolgen. 
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Patentanspriiche 

Verfahren zum Test eines objektorientierten Programmes (ol , o2, o3, o4\ 

a) bei dem niindestens ein Kommunikations-Vorgang (ma(x,y)) zwischen Objekten des Programmes in 15 
einem Protokoll (P) protokolliert wird, indem mindestens ein Programmteil des Programmes, welcher 
vom Kommunikationsvorgang betroffen ist, instrumentiert wird, 

b) und bei dem der Test (TAP) dadurch erfolgt, daB das Protokoll (P) ausgewertet wird 

2. Verfahren nach Anspruch 1, bei dem das Protokoll (P) automatisch in jenem grafischen Format aufberei- 

tet wird, in welchem die Spezifikation des objektorientierten Programms erfolgte, so daB das Programm 20 
gegen die Spezifikation getestet werden kann. 

3. Verfahren nach einem der Anspriiche 1 oder 2, bei dem Methoden (ma(x,y),mb(z^,c)) instrumentiert 
werden. 

4. Verfahren nach einem der vorhergehenden Anspruche, bei dem Methodenaufrufe instrumentiert werden. 

5. Verfahren nach einem der obigen Anspruche, bei dem Bilanzen erstellt werden. 25 

6. Verfahren nach Anspruch 6, bei dem Bilanzen tiber Klassen, oder Objekte, oder Methoden erstellt 
werden. 

7. Verfahren nach einem der obigen Anspruche, bei dem iiber eine statistische Auswertung die Wiederver- 
wendung mindestens einer in dem objektorientierten Programm eingefugten Klasse uberpriift wird 
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